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New Properties for iCalendar 


Abstract 
This document defines a set of new properties for iCalendar data and 
extends the use of some existing properties to the entire iCalendar 
object. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7986. 


Copyright Notice 


Copyright (c) 2016 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 


Daboo Standards Track [Page 1] 


RFC 7986 iCalendar Property Extensions October 2016 


Table of Contents 


di SETHE BAUER A o etree: eens te 3 
2. Conventions Used in This Document .....oooooooooooococoooonooooo.o.. 3 
3. Backwards-Compatible Extension Properties .....oo.ooooocooooooooo... 3 
4. Modifications to Calendar Components +....ooooooooooooooooo ooo... 4 
Su DEOPeEELLES! a e E ba 5 
Dake NAME PRODELEY ara a as 5 
Didi DESCRIPTION PROPEL EYS pa is cas 6 
553a UVID BEOpertyýy aaae A a cs 7 

Su Ls LAST-MODIFIED- Property ia A A A ES 8 
bed URL: PEOPerEY aii A Cae ee A eee e 8 
5.6). CATEGORIES- BEOPerkY Voce Sa a a a e Gad e a S E 8 
DT REERESH=INTERVA Property sd oria A a Ee or eevee el as 9 
90:18 SOURCE Property csrsesesa A T Cae SS eee a 10 

Ds Dl ¡COLOR Property tenia. ee eee eG ie Spe ecw! a eli Sele ane 10 

Se 0% IMAGE ¿PEOPLE as wisi ice: ahs eaten a ais aos 11 
Dells CONFERENCE ¡PEOPEREY" a a o aa 13 

6 Property Parameters? a asec ald ota el AE Neco had Bla lite Maca SS RD ok he 14 
6.1... DISPLAY: Property. Parameter ym is 14 
Sali EMAIL Property Parameter ina ais ra a 15 
6.3. FEATURE Property Parameter ....oooooooooooooooooooonoooooo.. 16 

0 4:.. ¡BABEL Property “Parameter > Vio e we Sete a es 17 

Ts. ¡Security Considerations rm A Sa AA AA a 18 
8 Privacy Considerations ses reses e eae a A a 18 
9+) TANA “CONSVOSTACLONS. eS IN A E EENE EOS 19 
9. Lo Property -RegistratiónS- ismael 19 
9.2), Parameter Registrations csc se gesa cda ra 20 
9.3. Property Parameter Value Registries ....o.ooooooooooooooooo.. 20 
1.0: References: sie ccd Se oid a la dhe e BE ON eae le eS 21 
LOL. Normative References” is ee bk dpe ea, A wee eased 21 
10:25 cInformatdve: References: isa as a eed 22 
Acknowledgments is A a, esate ws einen sake eee as ont a a 23 
Authors Address. deta a a a eS eae aie as 23 
Daboo Standards Track [Page 2] 


RFC 7986 iCalendar Property Extensions October 2016 


Les 


Introduction 


The iCalendar [RFC5545] data format is used to represent calendar 
data and is used with the iCalendar Transport-Independent 
Interoperability Protocol (iTIP) [RFC5546] to handle scheduling 
operations between calendar users. iCalendar is in widespread use, 
and in accordance with provisions in that specification, extension 
elements have been added by various vendors to the data format in 
order to support and enhance capabilities. This specification 
collects a number of these ad hoc extensions and uses the new IANA 
registry capability defined in [RFC5545] to register standard 
variants with clearly defined definitions and semantics. In 
addition, some new elements are introduced for features that vendors 
have recently been requesting. 


Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
[RFC2119]. 


The notation used in this memo is the ABNF notation of [RFC5234] as 
used by iCalendar [RFC5545]. Any syntax elements shown below that 
are not explicitly defined in this specification come from iCalendar 
[RFC5545]. 


Backwards-Compatible Extension Properties 


iCalendar defines properties that can have different value types 
indicated by a "VALUE" parameter. The definition of a property 
specifies a "default" value type that is assumed to be used when no 
"VALUE" parameter is present. However, this poses a problem to the 
iCalendar parser/generator software that does not know about the 
default values for new properties. For example, if a new property 
"FOO" were defined with a default value type of URI and a URI value 
with a comma was used, an iCalendar generator not aware of this fact 
would likely treat the property value as "TEXT" and apply backslash 
escaping to the comma in the value, effectively making it an invalid 
URI value. 


To avoid this problem, this specification recommends that all 
properties not defined in [RFC5545] always include a "VALUE" 
parameter if the type is other than "TEXT". That is, in the example 
above, the "FOO" property would have a "VALUE=URI" parameter. This 
allows iCalendar parser/generator software to track the correct types 
of unknown properties. 
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New properties defined in this specification use the term "no 
default" in the "Value Type" definition to indicate that the "VALUE" 
parameter has to be included. 


4. Modifications to Calendar Components 


This section details changes to the syntax defined in iCalendar 
[RFC5545]. New elements are defined in subsequent sections. 


calprops =/ * ( 
r 
; The following are OPTIONAL, 
; but MUST NOT occur more than once. 


1 

uid / last-mod / url / 

refresh / source / color 

7 

; The following are OPTIONAL, 

; and MAY occur more than once. 

7 

name / description / categories / 
image 

7 


) 
eventprop =/ * ( 


; The following are OPTIONAL, 
; but MUST NOT occur more than once. 


; The following are OPTIONAL, 
; and MAY occur more than once. 


conference / image 
i 


) 


todoprop =/ *( 
7 
; The following are OPTIONAL, 
; but MUST NOT occur more than once. 


r 

color / 

i 

; The following are OPTIONAL, 

; and MAY occur more than once. 
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i 
conference / image 
i 


) 
jourprop =/ * ( 


; The following are OPTIONAL, 
; but MUST NOT occur more than once. 


; The following are OPTIONAL, 
; and MAY occur more than once. 


image 
) 

5. Properties 

5.1. NAME Property 

Property Name: NAME 

Purpose: This property specifies the name of the calendar. 

Value Type: TEXT 

Property Parameters: IANA, non-standard, alternate text 
representation, and language property parameters can be specified 
on this property. 

Conformance: This property can be specified multiple times in an 
iCalendar object. However, each property MUST represent the name 
of the calendar in a different language. 

Description: This property is used to specify a name of the 
iCalendar object that can be used by calendar user agents when 
presenting the calendar data to a user. Whilst a calendar only 
has a single name, multiple language variants can be specified by 


including this property multiple times with different "LANGUAGE" 
parameter values on each. 
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Format Definition: This property is defined by the following 


notation: 

name = "NAME" nameparam ":" text CRLF 

nameparam = * ( 
The following are OPTIONAL, 
; but MUST NOT occur more than once. 
(un altrepparam) / (";" languageparam) / 
The following is OPTIONAL, 
; and MAY occur more than once. 
men other-param) 

Example: The following is an example of this property: 


NAME:Company Vacation Days 
5.2. DESCRIPTION Property 


This specification modifies the definition of the "DESCRIPTION" 
property to allow it to be defined in an iCalendar object. The 
following additions are made to the definition of this property, 
originally specified in Section 3.8.1.5 of [RFC5545]. 


Purpose: This property specifies the description of the calendar. 


Conformance: This property can be specified multiple times in an 
iCalendar object. However, each property MUST represent the 
description of the calendar in a different language. 


Description: This property is used to specify a lengthy textual 
description of the iCalendar object that can be used by calendar 
user agents when describing the nature of the calendar data to a 
user. Whilst a calendar only has a single description, multiple 
language variants can be specified by including this property 
multiple times with different "LANGUAGE" parameter values on each. 
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5.3. UID Property 


This specification modifies the definition of the "UID" property to 
allow it to be defined in an iCalendar object. The following 
additions are made to the definition of this property, originally 
specified in Section 3.8.4.7 of [RFC5545]. 


Purpose: This property specifies the persistent, globally unique 
identifier for the iCalendar object. This can be used, for 
example, to identify duplicate calendar streams that a client may 
have been given access to. It can be used in conjunction with the 
"LAST-MODIFIED" property also specified on the "VCALENDAR" object 
to identify the most recent version of a calendar. 


Conformance: This property can be specified once in an iCalendar 
object. 


The description of the "UID" property in [RFC5545] contains some 
recommendations on how the value can be constructed. In particular, 
it suggests use of host names, IP addresses, and domain names to 
construct the value. However, this is no longer considered good 
practice, particularly from a security and privacy standpoint, since 
use of such values can leak key information about a calendar user or 
their client and network environment. This specification updates 
[RFC5545] by stating that "UID" values MUST NOT include any data that 
might identify a user, host, domain, or any other security- or 
privacy-sensitive information. It is RECOMMENDED that calendar user 
agents now generate "UID" values that are hex-encoded random 
Universally Unique Identifier (UUID) values as defined in 

Sections 4.4 and 4.5 of [RFC4122]. 


The following is an example of such a property value: 

UID: 5FC53010-1267-4F8E-BC28-1D7AE55A7C99 

Additionally, if calendar user agents choose to use other forms of 
opaque identifiers for the "UID" value, they MUST have a length less 


than 255 octets and MUST conform to the "iana-token" ABNF syntax 
defined in Section 3.1 of [RFC5545]. 
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5.4. LAST-MODIFIED Property 


This specification modifies the definition of the "LAST-MODIFIED" 
property to allow it to be defined in an iCalendar object. The 
following additions are made to the definition of this property, 
originally specified in Section 3.8.7.3 of [RFC5545]. 


Purpose: This property specifies the date and time that the 
information associated with the calendar was last revised. 


Conformance: This property can be specified once in an iCalendar 
object. 


5.5. URL Property 


This specification modifies the definition of the "URL" property to 
allow it to be defined in an iCalendar object. The following 
additions are made to the definition of this property, originally 
specified in Section 3.8.4.6 of [RFC5545]. 


Purpose: This property may be used to convey a location where a more 
dynamic rendition of the calendar information can be found. 


Conformance: This property can be specified once in an iCalendar 
object. 


5.6. CATEGORIES Property 


This specification modifies the definition of the "CATEGORIES" 
property to allow it to be defined in an iCalendar object. The 
following additions are made to the definition of this property, 
originally specified in Section 3.8.1.2 of [RFC5545]. 


Purpose: This property defines the categories for an entire 
calendar. 
Conformance: This property can be specified multiple times in an 


iCalendar object. 


Description: When multiple properties are present, the set of 
categories that apply to the iCalendar object are the union of all 
the categories listed in each property value. 
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5.7. REFRESH-INTERVAL Property 
Property Name: REFRESH-INTERVAL 


Purpose: This property specifies a suggested minimum interval for 
polling for changes of the calendar data from the original source 
of that data. 


Value Type: DURATION -- no default 


Property Parameters: IANA and non-standard property parameters can 
be specified on this property. 


Conformance: This property can be specified once in an iCalendar 
object. 


Description: This property specifies a positive duration that gives 
a suggested minimum polling interval for checking for updates to 
the calendar data. The value of this property SHOULD be used by 
calendar user agents to limit the polling interval for calendar 
data updates to the minimum interval specified. 


Format Definition: This property is defined by the following 
notation: 


refresh = "REFRESH-INTERVAL" refreshparam 
":" dur-value CRLF 
¿consisting of a positive duration of time. 


refreshparam = *( 
7 
; The following is REQUIRED, 
; but MUST NOT occur more than once. 
7 


( " ; " " VALUE " n=" " DURAT F ON " ) / 


; The following is OPTIONAL, 
; and MAY occur more than once. 
i 


(";" other-param) 
i 
) 
Example: The following is an example of this property: 


REFRESH-INTERVAL; VALUE=DURATION:P1W 
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5.8. SOURCE Property 
Property Name: SOURCE 


Purpose: This property identifies a URI where calendar data can be 
refreshed from. 


Value Type: URI -- no default 


Property Parameters: IANA and non-standard property parameters can 
be specified on this property. 


Conformance: This property can be specified once in an iCalendar 
object. 


Description: This property identifies a location where a client can 
retrieve updated data for the calendar. Clients SHOULD honor any 
specified "REFRESH-INTERVAL" value when periodically retrieving 
data. Note that this property differs from the "URL" property in 
that "URL" is meant to provide an alternative representation of 
the calendar data rather than the original location of the data. 


Format Definition: This property is defined by the following 


notation: 
source = "SOURCE" sourceparam ":" uri CRLF 
sourceparam = *(";" other-param) 
Example: The following is an example of this property: 


SOURCE; VALUE=URI:https://example.com/holidays.ics 
5.9. COLOR Property 
Property Name: COLOR 


Purpose: This property specifies a color used for displaying the 
calendar, event, todo, or journal data. 


Value Type: TEXT 


Property Parameters: IANA and non-standard property parameters can 
be specified on this property. 


Conformance: This property can be specified once in an iCalendar 
object or in "VEVENT", "VTODO", or "VJOURNAL" calendar components. 
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Description: This property specifies a color that clients MAY use 
when presenting the relevant data to a user. Typically, this 
would appear as the "background" color of events or tasks. The 
value is a case-insensitive color name taken from the CSS3 set of 
names, defined in Section 4.3 of [W3C.REC-css3-color-20110607]. 


Format Definition: This property is defined by the following 


notation: 
color = "COLOR" colorparam ":" text CRLF 
; Value is CSS3 color name 
colorparam = *(";" other-param) 
Example: The following is an example of this property: 


COLOR: turquoise 
5.10. IMAGE Property 
Property Name: IMAGE 


Purpose: This property specifies an image associated with the 
calendar or a calendar component. 


Value Type: URI or BINARY -- no default. The value MUST be data 
with a media type of "image" or refer to such data. 


Property Parameters: IANA, non-standard, display, inline encoding, 
and value data type property parameters can be specified on this 
property. The format type parameter can be specified on this 
property and is RECOMMENDED for inline binary-encoded content 


information. 

Conformance: This property can be specified multiple times in an 
iCalendar object or in "VEVENT", "VTODO", or "VJOURNAL" calendar 
components. 


Description: This property specifies an image for an iCalendar 
object or a calendar component via a URI or directly with inline 
data that can be used by calendar user agents when presenting the 
calendar data to a user. Multiple properties MAY be used to 
specify alternative sets of images with, for example, varying 
media subtypes, resolutions, or sizes. When multiple properties 
are present, calendar user agents SHOULD display only one of them, 
picking one that provides the most appropriate image quality, or 
display none. The "DISPLAY" parameter is used to indicate the 
intended display mode for the image. The "ALTREP" parameter, 
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defined in [RFC5545], can be used to provide a "clickable" image 
where the URI in the parameter value can be "launched" by a click 
on the image in the calendar user agent. 


Format Definition: This property is defined by the following 


notation: 
image = "IMAGE" imageparam 
( 
( 
" A " " VALUE " now " URI " 
" z " uri 
) / 
( 
mae " "ENCODING" now "BASE64 " 
" ; " " VALUE " now " B I NARY " 
":" binary 
) 
) 
CRLF 
imageparam = * ( 
i 
; The following is OPTIONAL for a URI value, 
; RECOMMENDED for a BINARY value, 
; and MUST NOT occur more than once. 
7 
(";" fmttypeparam) / 
7 
; The following are OPTIONAL, 
; and MUST NOT occur more than once. 
r 
(";" altrepparam) / (";" displayparam) / 
7 
; The following is OPTIONAL, 
; and MAY occur more than once. 
A 
(";" other-param) 
1 
) 
Example: The following is an example of this property: 


IMAGE; VALUE=URI ; DISPLAY=BADGE; FMTTYPE=image/png:h 
ttp://example.com/images/party.png 
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5.11. CONFERENCE Property 
Property Name: CONFERENCE 


Purpose: This property specifies information for accessing a 
conferencing system. 


Value Type: URI -- no default. 


Property Parameters: IANA, non-standard, feature, and label property 
parameters can be specified on this property. 


Conformance: This property can be specified multiple times ina 
"VEVENT" or "VTODO" calendar component. 


Description: This property specifies information for accessing a 
conferencing system for attendees of a meeting or task. This 
might be for a telephone-based conference number dial-in with 
access codes included (such as a tel: URI [RFC3966] or a sip: or 
sips: URI [RFC3261]), for a web-based video chat (such as an http: 
or https: URI [RFC7230]), or for an instant messaging group chat 
room (such as an xmpp: URI [RFC5122]). If a specific URI fora 
conferencing system is not available, a data: URI [RFC2397] 
containing a text description can be used. 


A conference system can be a bidirectional communication channel 
or a uni-directional "broadcast feed". 


The "FEATURE" property parameter is used to describe the key 
capabilities of the conference system to allow a client to choose 
the ones that give the required level of interaction from a set of 
multiple properties. 


The "LABEL" property parameter is used to convey additional 
details on the use of the URI. For example, the URIs or access 
codes for the moderator and attendee of a teleconference system 
could be different, and the "LABEL" property parameter could be 
used to "tag" each "CONFERENCE" property to indicate which is 
which. 


The "LANGUAGE" property parameter can be used to specify the 
language used for text values used with this property (as per 
Section 3.2.10 of [RFC5545]). 
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Format Definition: This property is defined by the following 
notation: 


conference = "CONFERENCE" confparam ":" uri CRLF 


ll 
* 
pe 


confparam 


; The following is REQUIRED, 
; but MUST NOT occur more than once. 


( " ; " "VALUE " now " URI " ) / 


; The following are OPTIONAL, 

; and MUST NOT occur more than once. 
A 

(";" featureparam) / (";" labelparam) / 
(";" languageparam ) / 

; The following is OPTIONAL, 

; and MAY occur more than once. 


`e 


(";" other-param) 
) 


Example: The following are examples of this property: 


CONFERENCE; VALUE=URI; FEATURE=PHONE, MODERATOR; 

LABEL=Moderator dial-in:tel:+1-412-555-0123,,,654321 
CONFERENCE; VALUE=URI; FEATURE=PHONE; 

LABEL=Attendee dial-in:tel:+1-412-555-0123,,,555123 

CONFERENCE; VALUE=URI; FEATURE=PHONE; 

LABEL=Attendee dial-in:tel:+1-888-555-0456,,,555123 

CONFERENCE; VALUE=URI; FEATURE=CHAT; 

LABEL=Chat room: xmpp:chat-123@conference.example.com 
CONFERENCE; VALUE=URI; FEATURE=AUDIO, VIDEO; 

LABEL=Attendee dial-in:https://chat.example.com/audio?id=123456 


6. Property Parameters 
6.1. DISPLAY Property Parameter 
Parameter Name: DISPLAY 


Purpose: To specify different ways in which an image for a calendar 
or component can be displayed. 
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Format Definition: This property parameter is defined by the 
following notation: 


displayparam = "DISPLAY" "=" displayval *("," displayval) 
displayval = ("BADGE" / ; image inline with the title of the 
; event 
"GRAPHIC" / ; a full image replacement for the event 
; itself 
"FULLSIZE" / ; an image that is used to enhance the 
; event 


"THUMBNAIL" / ; a smaller variant of "FULLSIZE" to be 
; used when space for the image is 


; constrained 
x-name / ; Experimental type 
iana-token) ; Other IANA-registered type 


; Default is BADGE 


Description: This property parameter MAY be specified on "IMAGE" 
properties. In the absence of this parameter, the default value 
"BADGE" MUST be used. The value determines how a client ought to 
present an image supplied in iCalendar data to the user. 


Values for this parameter are registered with IANA as per 
Section 9.3.1. New values can be added to this registry following 


the procedure outlined in Section 8.2.1 of [RFC5545]. 


Servers and clients MUST handle x-name and iana-token values they 
don’t recognize by not displaying any image at all. 


Example: 


IMAGE; VALUE=URI ; DISPLAY=BADGE, THUMBNAIL; FMTTYPE=image/png:https://exa 
mple.com/images/weather-cloudy.png 


6.2. EMAIL Property Parameter 
Parameter Name: EMAIL 


Purpose: To specify an email address that is used to identify or 
contact an organizer or attendee. 


Format Definition: This property parameter is defined by the 
following notation: 


emailparam = "EMAIL" "=" param-value 


Daboo Standards Track [Page 15] 


RFC 7986 iCalendar Property Extensions October 2016 


Description: This property parameter MAY be specified on "ORGANIZER" 


or “ATTENDEE" properties. This property can be used in situations 
where the calendar user address value of the "ORGANIZER" and 
"ATTENDEE" properties is not likely to be an identifier that 
recipients of scheduling messages could use to match the calendar 
user with, for example, an address book entry. The value of this 
property is an email address that can easily be matched by 
recipients. Recipients can also use this value as an alternative 
means of contacting the calendar user via email. If a recipient’s 
calendar user agent allows the recipient to save contact 
information based on the "ORGANIZER" or "ATTENDEE" properties, 
those calendar user agents SHOULD use any "EMAIL" property 
parameter value for the email address of the contact over any 
mailto: calendar user address specified as the value of the 
property. Calendar user agents SHOULD NOT include an "EMAIL" 
property parameter when its value matches the calendar user 
address specified as the value of the property. 


Example: 


ATTENDEE; CN=Cyrus Daboo;EMAIL=cyrus@example.com:mailto:opaque-toke 


n- 


653% 


1234@example.com 


FEATURE Property Parameter 


Parameter Name: FEATURE 


Purpose: To specify a feature or features of a conference or 


broadcast system. 


Format Definition: This property parameter is defined by the 


following notation: 


featureparam = "FEATURE" "=" featuretext *("," featuretext) 
featuretext = ("AUDIO" / ; Audio capability 
"CHAT" / ; Chat or instant messaging 
"FEED" / ; Blog or Atom feed 
"MODERATOR" / ; Moderator dial-in code 
"PHONE" / ; Phone conference 
"SCREEN" / ; Screen sharing 
"VIDEO" / ; Video capability 
x-name / ; Experimental type 
iana-token) ; Other IANA-registered type 
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Description: This property parameter MAY be specified on the 
"CONFERENCE" property. Multiple values can be specified. The 
"MODERATOR" value is used to indicate that the property value is 
specific to the owner/initiator of the conference and contains a 
URI that "activates" the system (e.g., a "moderator" access code 
for a phone conference system that is different from the "regular" 
access code). 


Example: 


CONFERENCE; VALUE=URI; FEATURE=AUDIO: rtsp://audio.example.com/ 
event 

CONFERENCE; VALUE=URI ; FEATURE=AUDIO, VIDEO: https://video-chat.exam 
ple.com/; group-id=1234 


6.4. LABEL Property Parameter 
Parameter Name: LABEL 
Purpose: To provide a human-readable label. 


Format Definition: This property parameter is defined by the 
following notation: 


labelparam = "LABEL" "=" param-value 


Description: This property parameter MAY be specified on the 
"CONFERENCE" property. It is anticipated that other extensions to 
iCalendar will reuse this property parameter on new properties 
that they define. As a result, clients MUST expect to find this 
property parameter present on many different properties. It 
provides a human-readable label that can be presented to calendar 
users to allow them to discriminate between properties that might 
be similar or provide additional information for properties that 
are not self-describing. The "LANGUAGE" property parameter can be 
used to specify the language of the text in the parameter value 
(as per Section 3.2.10 of [RFC5545]). 


Example: 
CONFERENCE; VALUE=URI; FEATURE=VIDEO; 


LABEL="Web video chat, access code=76543"; 
:https://video-chat .example.com/;group-id=1234 
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7. 


Security Considerations 


Several of the new properties or parameters defined by this 
specification allow reference to "external" URIs. Care MUST be taken 
when accessing data at external URIs as malicious content could be 
present. Clients SHOULD ensure that suitable permission is granted 
by calendar users before such URIs are dereferenced. 


The "REFRESH-INTERVAL" property could be used by an attacker to make 
a client carry out rapid requests to the server hosting the calendar 
by specifying a very short duration (e.g., one second). This could 
lead to resource consumption on the client or server and to denial- 
of-service attacks against the server. Clients MUST ensure that they 
throttle requests to the server to a reasonable rate. In most cases, 
updating a public calendar once per day would suffice. If the 
"REFRESH-INTERVAL" is any less than that, clients SHOULD warn the 
calendar user and allow them to override it with a longer value. 


The "CONFERENCE" property can include a "FEATURE" property parameter 
with a "MODERATOR" value. In some cases, the access code used by the 
owner/initiator of a conference might be private to an individual, 
and clients and servers MUST ensure that such properties are not sent 
to attendees of a scheduled component. 


Both the "COLOR" and "IMAGE" properties are likely to be used by 
calendar users to express their own personal view of the calendar 
data. In addition, these properties could be used by attackers to 
produce a confusing display in a calendar user agent. When such 
properties are encountered in calendar data that has come from other 
calendar users (e.g., via a scheduling message, "public" calendar 
subscription, etc.), it is advisable for the client to give the 
receiving calendar user the option to remove (or adjust) these 
properties as the data is imported into their calendar system. 


This specification changes the recommendations on how "UID" property 
values are constructed to minimize leaking any information that might 
be security sensitive. 


Security considerations in [RFC5545] and [RFC5546] MUST also be 
adhered to. 


Privacy Considerations 


Several of the new properties or parameters defined by this 
specification allow reference to "external" URIs. Access to those 
URIs could be tracked, leading to loss of privacy. Clients SHOULD 
ensure that suitable permission is granted by calendar users before 
such URIs are dereferenced. In particular, calendar publishers 
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9. 


9. 


wishing to help protect the privacy of their subscribers MUST use 
HTTP with Transport Layer Security [RFC7230] ("https:" URIs instead 
of "http:" URIs) for access to calendar data or ancillary data such 
as images. 


In general, for their own privacy protection, users have to rely on 
the privacy policies of any conferencing system being accessed via 
the "CONFERENCE" property. It is entirely possible for such systems 
to uniquely identify and log the activity and participation (or lack 
thereof) of calendar users in the conference. Calendar user agents 
SHOULD track which conferencing systems are used and warn users the 
first time a new one is about to be used. This is particularly 
important if the client automatically "dials in" to the conference 
when the event start time occurs. 


By giving different calendar users different values for the "REFRESH- 
INTERVAL" property, it is possible for a publisher of calendar data 
to uniquely identify each refresh from each calendar users” clients 
and thereby track user activity and IP address over time. To address 
this, clients SHOULD add or subtract some random amount of time from 
the published "REFRESH-INTERVAL" value when doing actual refreshes. 


This specification changes the recommendations on how "UID" property 
values are constructed to minimize leaking any information that might 
be privacy sensitive. 


Privacy considerations in [RFC5545] and [RFC5546] MUST also be 
adhered to. 


IANA Considerations 
1. Property Registrations 


This document defines the following new iCalendar properties. IANA 
has registered the new properties in the "Properties" registry 
defined in Section 8.3.2 of [RFC5545]. IANA has also added a 
reference to this document where the properties originally defined in 
RFC 5545 have been updated by this document. 
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4+------------------ 4+-------- 
| Property | Status 
4+------------------ 4+-------- 
| NAME | Current 
| DESCRIPTION | Current 
| | 
| UID | Current 
| | 
| LAST-MODIFIED | Current 
| URL | Current 
| | 
| CATEGORIES | Current 
| | 
| REFRESH-INTERVAL | Current 
SOURCE Current 
COLOR Current 
| IMAGE | Current 
| CONFERENCE | Current 
4+------------------ 4+-------- 
9.2. Parameter Registrations 


Property Extensions 


Reference 


Section 
Section 


<2 


Section 


23 


Section 


.4 


Section 


ao) 


Section 


6 


Section 
Section 
Section 
Section 
Section 
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WA AAA A A Se er SS Se Se ree + 


| 
5.1 | 
3.8.1.5; RFC 7986, | 
| 
3.8.4.7; RFC 7986, | 
| 
3.8.7.3 RFC 7986, | 
3.8.4.6; RFC 7986, | 
| 
3.8.1.2; RFC 7986, | 
| 
5x7 | 
5.8 
5.9 
5 LO | 
5.11 | 


This document defines the following new iCalendar property 
parameters. IANA has registered these in the "Parameters" registry 
defined in Section 8.3.3 of [RFC5545]. 


AZ E T Ho + 
| Property Parameter | Status | Reference 
$ Ho + 
| DISPLAY | Current | RFC 7986, 
| EMAIL | Current | RFC 7986, 
| FEATURE | Current | RFC 7986, 
| LABEL | Current | RFC 7986, 
$ S Ho + 

9.3. Property Parameter Value Registries 


A A A O A A RN i + 


| 
Section 6.1 | 
Section 6.2 | 
Section 6.3 | 
Section 6.4 | 


IANA has created two new registries for iCalendar elements: the 
"Display Types" registry and the "Feature Types" registry. 

Additional codes MAY be used, provided the process and template 
described in Sections 8.2.1 and 8.2.6 of [RFC5545] are used to 


register them. 
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9.3.1. Display Types Registry 


The following table has been used 


registry. 


4+-------------- 4+--------- 
| Display Type | Status 
4+-------------- 4+--------- 
BADGE Current 
GRAPHIC Current 
| FULLSIZE | Current 
| THUMBNAIL | Current 
4+-------------- 4+--------- 


9.3.2. Feature Types Registry 


The following table has been used 


October 2016 


to initialize the "Display Types" 


$ + 

| Reference | 

$ + 
RFC 7986, Section 6.1 
RFC 7986, Section 6.1 

| REC 7986, Section 6.1 | 

| REC 7986, Section 6.1 | 

+----------------------- + 


to initiali 


ze the "Feature Types" 


registry. 
+-------------- +--------- 4+----------------------- + 
| Feature Type | Status | Reference 
+-------------- 4+--------- Ho + 
| AUDIO | Current | RFC 7986, Section 6.3 | 
| CHAT | Current | RFC 7986, Section 6.3 | 
| FEED | Current | RFC 7986, Section 6.3 | 
| MODERATOR | Current | RFC 7986, Section 6.3 | 
| PHONE | Current | RFC 7986, Section 6.3 | 
SCREEN Current RFC 7986, Section 6.3 
VIDEO Current RFC 7986, Section 6.3 
4+-------------- +--------- Ho + 
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